- Rework the input's invalid JSON sanitization feature to support configurable sanitizers
- Migrate existing sanitizers to the new format
- Add a new `replace_all` sanitizer
- Add a new `invalid_json_messages_total` input metric to count the number of messages that contain invalid JSON strings.

The `replace_all` sanitizer replaces all the occurrences of substring matching the regex expression `pattern` with a fixed literal string `replacement`.

Here is a sample configuration:

```yaml
sanitizers:
- type: replace_all
  spec:
    pattern: '\[\s*([^\[\]{},\s]+(?:\s+[^\[\]{},\s]+)*)\s*\]'
    replacement: "{}"
```

For example, if the diagnostic settings send the following message:

```json
{
    "AppImage": "orcas/postgres_standalone_16_u18:38.1.240825",
    "AppType": "PostgreSQL",
    "properties": [
        218 B blob data
    ]
}
```

With the previous sample configuration, the input will replace the invalid JSON, updating the message to the following version:

```json
{
    "AppImage": "orcas/postgres_standalone_16_u18:38.1.240825",
    "AppType": "PostgreSQL",
    "properties": {}
}
```

The `replace_all` sanitizer aims to restore JSON syntax validity by replacing invalid, unfixable JSON with literal values that make sense for the context.

The invalid JSON sanitization became a thing when we faced Azure services producing malformed JSON documents.

Here is a list of previous occurrences of this problem:

- #34092
- https://github.com/elastic/azuremarketplacedev/issues/190

In all cases, we first contacted Azure support, but they didn't fix the invalid JSON.

---------

Co-authored-by: Gabriel Pop <94497545+gpop63@users.noreply.github.com>
(cherry picked from commit 168b13a)